Oracle TimesTen In-Memory Databaseアーキテクチャ概要

アプリケーション設計の検討

TimesTenは最大の柔軟性を備えることで、広範囲のアプリケーション・アーキテクチャに対応できるように設計されています。たとえば、「使用例3: オンライン旅行代理店のアプリケーション」で説明したオンライン旅行代理店のアプリケーションについて、次の代替案を検討してみます。

代替案1

CustomTravel.comは、多数の顧客の同時セッションを効率的に管理するために、そのオンライン旅行代理店アプリケーションとして、図2.6に示すような、より集中型のアーキテクチャを選択できます。

この代替アーキテクチャでは、航空会社サービス、ホテル・サービス、レンタカー・サービスを提供するために、会社は個別のアプリケーションを実装します。各アプリケーションは、中央に位置する個別のサーバーで実行し、そのアプリケーションに関連するデータのみをキャッシュします。このアーキテクチャは、元の使用例で説明したものと同じ利点を持ちますが、データ管理に対してより集中型のアプローチを使用します。

図2.6 同じ位置に配置された複数のサーバー上の集中型TimesTenキャッシュ

代替案2

使用例3の3つのアプリケーションについて、サーバーが3つのアプリケーションをすべて処理できるだけの十分な能力を備えている場合は、図2.7に示すように、同一のサーバー上で実行できます。

図2.7 同一サーバー上の集中型TimesTenキャッシュ

代替案3

使用例3の3つのアプリケーションが同一サーバー上で実行される場合、図2.8に示すように、同一のTimesTenデータ・ストアにアクセスすることができます。つまり、3つのアプリケーションに必要なデータを単一のデータ・ストアに集めることができます。

図2.8 同一サーバー上の集中型の共有TimesTenキャッシュ

アーキテクチャ上のトレードオフ

前述の元の使用例3の設計と代替案の設計には、次のアーキテクチャ上のトレードオフがあります。

元の使用例3で説明したように、地理的に分散したサーバーでは、ローカル・アプリケーションとエンド・ユーザーへのレスポンス時間が短くなります。また、より優れたフォルト・トレランスも実現できます。これは、中央に集中配置された複数サーバーの場合、すべてが停電や火災などの同一の障害を受ける可能性があるためです。

代替案1で示したように、同一サイトの複数サーバーは、1台の大規模集中型サーバーより優れたフォルト・トレランスを実現できますが、より多くの管理オーバーヘッドと調整が必要となります。

複数の専用アプリケーションは、1つの汎用アプリケーションより、ソフトウェア障害に対して優れたフォルト・トレランスを実現できます。たとえば、代替案1では、航空サービス・アプリケーションの不具合は、レンタカー・サービス・アプリケーションに影響を及ぼしません。一方、元の使用例の場合、すべての予約サービスが1つのアプリケーションに結合されているため、アプリケーションの1つに不具合があると、そのノード上のすべてのサービスに影響が及ぶ可能性があります。

各アプリケーションは異なるアクセス・パターンを持ち、データに対して異なる索引を必要とする可能性があるため、異なってはいても、潜在的に重複しているデータ・ストアを持つ複数の専用アプリケーション（代替案2）の方が、単一のデータ・ストアを共有している複数のアプリケーション（代替案3）より優れたパフォーマンスを提供できます。

代替案3で説明した単一の共有データ・ストアには、メリットとデメリットがそれぞれいくつかあります。メリットは、TimesTenとOracle間でデータ送信をいつ、どのように行うかというすべてのポリシーを一箇所で処理できるので、データの管理が容易になることです。また、複数のキャッシュに冗長なデータが含まれる可能性があるため、メイン・メモリーの消費も節約できます。ただし、パフォーマンスとスケーラビリティは、複数のデータ・ストアの方が優れている場合があります。さらに、単一の共有データ・ストアで障害が発生すると、すべてのアプリケーションに影響が及ぶ可能性があります。ただし、このような障害発生時には、スタンバイ・データ・ストアによって迅速なフェイルオーバーが行われます。

設計オプションのまとめ

TimesTenへの接続

最高のパフォーマンスを得るには、「ダイレクト・ドライバ接続」で説明するTimesTen Data Managerへの直接接続を使用します。直接接続では、クライアント/サーバー接続に関連する高コストのコンテキスト・スイッチとIPCが回避されます。

ディスク・ベースのRDBMSを使用した処理

比較的少量から適度な量（1桁から数十GBの範囲）のデータ管理にはTimesTenが適していますが、大量（TBの範囲）のデータ管理には、Oracleデータベースのようなディスク・ベースのRDBMSの方が適しています。

TimesTenでは、Oracleデータベースと連携して処理を行うことができます。この場合、TimesTenは高パフォーマンスが必要な業務系データを管理し、Oracleデータベースは履歴データを管理します。これは、使用例1: 携帯利用者の利用状況計測アプリケーションと使用例3: オンライン旅行代理店のアプリケーションで示しました。TimesTenをOracleデータベースとともに使用する場合、いくつかのオプションが使用可能です。

TimesTenとOracleデータベース間のデータ転送は、アプリケーション（使用例1を参照）またはTimesTenのCache Connect to Oracle機能（使用例3を参照）で処理できます。

後で履歴Oracleデータベースにバッチで送信される新しい受信データは、TimesTenを使用して迅速に収集できます（使用例1を参照）。

頻繁にアクセスされる大規模データベースのサブセットは、TimesTenを使用して管理できます（使用例3を参照）。

業務系データは、複数のTimesTenデータ・ストアまたは単一のデータ・ストアで管理できます。複数のデータ・ストアの場合、データ・ストアは重複するか、あるいは完全にばらばらです。使用例3の代替案で説明したように、複数のデータ・ストアには、特定のアプリケーションが必要とする利点（拡張性、フォルト・トレランス、および潜在的により優れた調整機能）があります。

データのパーティション化

データのパーティション化を使用すると、アプリケーションを拡張し、スループットを向上させることができます。これは、携帯利用者の情報が異なるノードで収集される、使用例1: 携帯利用者の利用状況計測アプリケーションで示されています。既存のノードの容量が一杯になった場合、さらにノードを追加できるため、このパーティション化によって、アプリケーションは無限に拡張できるようになります。また、このようなパーティション化は地理的な柔軟性も提供し、携帯利用者が通話の開始と終了の間に移動しても、異なるノードを使用して、携帯利用者のデータを収集できます。

データの可用性

TimesTenが管理するデータの連続的な可用性は、「TimesTenアプリケーション使用例」で説明した3つの使用例すべてにおいて必須になります。これは、別のTimesTenデータ・ストアでデータのスタンバイ・コピーを常時保持することで実現されます。使用例1: 携帯利用者の利用状況計測アプリケーションと使用例3: オンライン旅行代理店のアプリケーションでは、スタンバイ・コピーはTimesTenのレプリケーション機能によって保持されます。一方、使用例2: リアルタイム取引価格サービス・アプリケーションでは、アプリケーションによるマスターとスタンバイの両方での冗長メッセージ機能とメッセージの冗長処理を介して、データ・ストアのスタンバイ・コピーが保持されます。

TimesTenレプリケーションでは、非同期とより同期に近いリターン・サービスのオプションが提供されます。マスター・データ・ストアで障害が発生した場合、TimesTenレプリケーションを使用して、スタンバイ・データ・ストアへの迅速なフェイルオーバーを有効にできます。使用例1と3では、アプリケーションはマスター・データ・ストアに対して実行されます。TimesTenはマスター・データ・ストアからスタンバイ・データ・ストアに、すべての更新を自動的にレプリケートします。マスター・データ・ストアで障害が発生すると、OS固有のクラスタ・マネージャが障害を検出し、すべてのアクティビティをスタンバイ・データ・ストアで実行するアプリケーションに自動的に切り替えます。

メッセージング・ミドルウェアによって、アプリケーションに更新を配信する環境では、アプリケーションで、冗長メッセージ機能を介して高可用性を実現する場合があります。この場合、メッセージング・ミドルウェアはプライマリとスタンバイの両方にメッセージを配信します。プライマリとスタンバイの両方のアプリケーションは、それぞれ互いのデータ・ストアに更新を適用します。読取りリクエストは、プライマリのみ、またはプライマリとスタンバイの両方によって処理されます。また、障害が発生した場合は、クラスタ・マネージャが障害を検出し、障害の発生していないデータ・ストアにリクエストを自動的に送信します。